A variety of software development tools (or “SDTs”) is available to software developers, and can provide functionality to assist in the creation and/or modification of software programs (or “applications”) that include actual GUIs.
Some SDTs may abstract software to be generated in various ways, and may then provide functionality related to that abstraction. For example, some SDTs may support a layered architecture in which objects in a given layer depend on objects in the next lower layer and are insulated from other layers in the structure. One such layered structure includes a logical user interface objects layer (e.g., that includes user interface objects to define the visual interface that a user sees and interacts with), a business objects layer (e.g., that includes business objects to combine data from data objects into logical data constructs for presentation to the user by user interface objects), and a data objects layer (e.g., that includes data objects to provide a logical representation of data structures from underlying databases in order to provide access to those data structures by business objects). SDTs with such a layered structure may allow corresponding objects to be defined at some or all of the layers as part of a software program being generated.
Objects can also be used in various ways by SDTs, such as by having each object implement one piece of a software program being generated. Such software program pieces implemented by objects may include, for example, an element of a user interface (e.g., a popup window for record selection), an abstract data representation (e.g., a database column), or a direct database representation or construct (e.g., a join relationship between database tables). Properties of such an object may represent characteristics of the software construct that the object implements (e.g., the name, data type, and length of a database column, or the title bar caption of a popup window). Some SDTs may also support hierarchical (or parent-child) relationships between different objects, such as when a parent object represents a table and child objects represent columns of the table.
SDTs may represent created objects in various ways, such as with a set of properties having assigned values. The created objects may be implemented directly as an object in an underlying object-oriented programming language (e.g., C++), or instead may be abstracted in various ways. In addition, some or all objects may have assigned sets of behaviors, such as by having an associated set of one or more software routines (e.g., via a DLL assigned to the object). An SDT may also provide one or more existing objects, such as a core set of objects, and allow a user to use those existing objects as a basis for an application being generated.
In addition, some SDTs may provide various tools to assist in creating objects. For example, software wizards may be provided for each of various object types to step users through the process of creating and configuring objects of those types. For example, a wizard may guide the user through providing various types of information, and then use that information to specify property settings for the object being created. Different wizards may be available from some SDTs for a variety of object types, such as table applets, chart applets, tree applets, form applets, multi-value group applets, pick list applets, views, screens, etc. In addition, tools may be available to validate created objects to help ensure that the objects are logically consistent, such as to check for invalid references to other objects.
As mentioned above, some SDTs may allow logical user interface objects to be specified for a software program in order to define the visual interface that a user of the software program will interact with. Such user interface objects may present data to users for viewing and/or modification, such as data from business objects. A variety of user interface elements may be represented by user interface objects, including control toolbar and menu elements, dropdown lists, view tabs, screen tabs, menu buttons, control buttons, etc.
One example of a type of logical user interface object in some SDTs is an “applet” object type that is used to implement higher-level user interface elements composed of lower-level user interface elements, such as data controls, editable scrolling tables, forms for data entry, business graphics, pop-up windows for multi-value groups and record selection, etc. that are composed of controls such as a text box, check box, command button, etc. For some SDTs, an applet provides access to the data of a single business component (e.g., for viewing, editing, and modifying fields in the business component), and may be able to be configured to allow data entry for a single record, to provide a scrolling table displaying multiple records, or to display business graphics or a navigation tree.
Some SDTs may also support a “view” user interface object type that is used to present one or more other user interface objects (e.g., applet objects) together at one time in a predefined visual arrangement and logical data relationship. Views may have names, and in some user interfaces may be selected by name from menus and/or displayed tab symbols. For some SDTs, each view is mapped to a single business object, and if so each applet in such a view may map to a business component in that business object.
Some SDTs may also support “screens” that are a collection of one or more related views, such as with an appropriate screen user interface object type. For some SDTs, all views in some or all screens are mapped to the same business object. In addition, for some SDTs a screen is not a visual construct itself, but is instead a logical collection of views to be displayed together.
Some SDTs may use a collection of screens as a user interface for a software program. In some situations, an application may have one or more associated URLs that a user may specify to access the application, such as when a Web engine will be used to generate HTML pages to present the screens. One or more page tabs may be displayed, with each page tab object associated with a screen of the application.
The various existing SDTs store the objects that comprise the software programs and the GUIs in a normalized form in a database. Because of the manner in which the objects are stored in the database, the objects have no meaning or, at a minimum, lose their meaning, apart from the software program and the GUIs to which the objects belong. While the existing SDTs assist in generating the software programs and GUIs, they do not facilitate direct access of the objects from the database in a meaningful manner. In order to access these objects within their proper context, for example, to place the objects into a test tool's repository in order to test the functionality of a software program and the GUIs, the test tool is required to access the objects via the software program and the GUIs.